QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930051.txt

Internet Message Format | 1994-06-04 | 48KB

Date: Tue, 23 Feb 93 04:30:07 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #51
To: tcp-group-digest


TCP-Group Digest            Tue, 23 Feb 93       Volume 93 : Issue   51

Today's Topics:

                              Atari NOS
                         AX.25 and callsigns
                    FEC in amateur radio (3 msgs)
                         Ignoring ARP request
                               jnos108
                         jnos108 repeat query
                        ka9q0105 and ftpusers
      looooooooooooooooooooooooooooooooooooong messages (3 msgs)
                              my BM mod
                          New ax25? (6 msgs)
                        On dealing with radar
                  physical layer and FEC engineering
                        redoing amateur packet
                     Riff-raff and the internet?
                              Slow Mail
                         Slow mail? (2 msgs)
                        stat() in Borland C++
                        Stat - Hello wake up !

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 23 Feb 93 09:09:16 MET
From: [e-mail]
Subject:
To: [e-mail]

 Is there a (packet)driver available for the DEPCA DE-200
 board ?

 /Lars

------------------------------

Date: Tue, 23 Feb 93 10:40:50 MET
From: [e-mail] (Mario Illgen)
Subject: Atari NOS
To: [e-mail]

Hi John,
thanks for your mail.
>
> KISS or SLIP mode up to it. What advantages (other than being NOS) does
> your port have over CHL? In particular, I'd would find it useful if it
> ran in background.
>
Sorry to disappoint you, but my NOS runs not int the background (as an
.ACC). But you have full access to the menu bar so, if you run MiNT with
TOSWIN or (hopefully soon) MTOS, you can run other applications parallel.
I think the main advantage is the user interface. It is an real GEM program
where every session has it's own window (there is also a trace session in
an extra window). And it is NOS :-) The port based on GRINOS v1.7j and
I have included the mailbox of GRINOS 2.0.

> Why not use PE1CHL's scc card for your system. I don't see the point in
> re-inventing the wheel.
>
That's my problem, I'm still looking for the wiring of this card and (if it
exists) the board layout. Are these informations available (and where)?

73! de Mario, DL3LSM
--
**********************************************************************
*     Mario Illgen    *  INTERNET: [e-mail]  *
*     TU Chemnitz     *                                              *
*     FB Informatik   *  AX25 BBS: [e-mail]              *
**********************************************************************

------------------------------

Date: Tue, 23 Feb 93 08:38:22 +1100
From: [e-mail] (Mike Walker)
Subject: AX.25 and callsigns
To: [e-mail]

How about we drop these silly alphanumeric callsigns and replace them
with a 32 bit hex address for everything.  That should stir up the old
CW freaks.

CQCQCQ de 120AEE2311AC9F0E

Mike
VK3ZMF       :-/

------------------------------

Date: Mon, 22 Feb 1993 11:30:24 -0500
From: [e-mail] (k1io, FN42jk)
Subject: FEC in amateur radio
To: [e-mail]

Comparing Reed-Solomon (block) coding with Phil's idea of using
convolutional coding, I sympathize with Phil's aims:  Block coding
doesn't work terribly well with variable-lenght data, for the
same reason ATM has overhead:  An R-S block is like a cell and has
to be padded out.  Also it has to be R-S decoded, while convolutional
decoding is optional.  The main advantage of R-S seems to be chip
availability, presuming that CD chips are available on the cheap.

But what's the best convolutional code to use?  Phil mentions one
that has 50% efficiency, but makes up for it in part by only sending
the FEC bits if the original bits fail.  How hard is that code to
handle in software or (cheap, available) hardware?  Perhaps the one
Phil mentioned is easy enough.  Then the second question arises,
is there a convolutional code with greater than 50% efficiency that
will handle the types of errors we are likely to see on packet radio?
What about, for example (and I don't know the properties) CRC-56
(isn't that what cheap disks use?) and CRC-64?  Are they adequate
and if so, up to what frame sizes?  With decent protocols, there's
no reason to need large frames; we can simply define a transmission
as being longer than one frame (i.e., FDDI's TTRT)  and, if the
FEC isn't good enough, use a selective recovery protocol (Checkpoint
Selective Reject comes to mind).

Lots of room for experimentation here...
   fred k1io

------------------------------

Date: Mon, 22 Feb 1993 14:09:06 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: FEC in amateur radio
To: Adrian Godwin <[e-mail]>

> perhaps you should synchronise to the interference source
> and transmit only in the gaps.

I think there's a random element to the repetition rate to jam-proof the
radar. If it were very predictable, it could be spoofed. Thus,
transmitting in the gaps may not be an option.

Around here, we aim a second antenna at the base where it's located.
If it can hear you, it won't transmit on that frequency.

     Bruce

------------------------------

Date: Tue, 23 Feb 93 12:08:24 PST
From: "Jerzy Tarasiuk" <[e-mail]>
Subject: FEC in amateur radio
To: [e-mail]

> Date: Sat, 20 Feb 93 13:11:24 -0800
> Message-Id: <[e-mail]>
> From: Phil Karn <[e-mail]> (Phil Karn)
> Consider a typical military radar with a 400 Hz rep rate, a 8 Mhz bandwidth,
> a 10 second antenna sweep rate, and a 20 microsecond pulse width (this

> Message-Id: <[e-mail]>
> Date: Mon, 22 Feb 1993 11:30:24 -0500
> From: [e-mail] (k1io, FN42jk)
> What about, for example (and I don't know the properties) CRC-56
> (isn't that what cheap disks use?) and CRC-64?  Are they adequate

Hello,
I don't know any easy way to recover original data having CRC if errors
are in many places. CRC is good if have you single burnst of errors - a
way to recover original data is: compute CRC of data+CRC received, then
compute CRC "back" until width of non-zero part of it is small enough
(can do it for entire data to find most probable place). Probably disk
controllers use similar way and as I remember they allow recevering
original data when several consecutive bits are lost due to error.

For the particular case of radar destroying data bits with exactly
known frequency: I remember old CDC 6400 machine and its 9-track 800
BPI (NRZI coding) tape controller, it was capable to recover correct
data when one of coins of head was damaged and drive was reading 8
of the 9 tracks only. The algorithm required all errors to be on one
bit position; it used one parity bit for every byte and 9 bit CRC for
entire block, the CRC was used to find which coin was bad.
More efficient error correction was used for 1600 BPI (Phase Encoded)
- when bit was unreliable, decoder knew which bit and parity bit
allowed to correct byte (possible to get correct data if only single
error in every byte). The second can be probably applied to packet
radio to recover data destroyed by radar QRM if computer gets QRM
information (knows which bits of data were destroyed by the QRM).

This would require sender to insert some extra parity bits, e.g. 2 per
16 bytes (one is XOR of all odd, second of all even bits); assuming the
400Hz rep rate and 56kbaud we get one or two data bits destroyed per
140; the receiver must check QRM signal from pulse blanker and set the
bit(s) received during QRM to proper value(s) to get good parity for
the 16-byte block. This is relatively simple algorithm and the error
correction should be done by a hardware rather than a software.
73's, JT

------------------------------

Date: 22 Feb 93 08:17:38 CST
From: Jack Snodgrass <[e-mail]>
Subject: Ignoring ARP request
To: <[e-mail]>

Is there a way to ignore arp request on a specific interface? I have a
lan connection that gets flooded with ARP request. I'm 'hearing' several
arp request per second. I'm also running out of storage, and I think
that it might be because of processing all the arp commands. I sent a
note to the 2 machines that are sending out the request. I got a note
back saying that they were doing some kind of network management and
they were supposed to be arping everyone constantly. Doesn't seem to
do much for performance. Thanks.

73's  de  Jack - kf5mg
AMPRnet         -  [e-mail]       - 44.28.0.14
AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - work [phone]
Internet        -  [e-mail]         - home [phone]

------------------------------

Date: Mon, 22 Feb 93 14:23:20 -0800
From: (Johan K. Reinalda) <[e-mail]>
Subject: jnos108
To: [e-mail], [e-mail]

Is out. It contains

-improved BID handling in smtp server (rejection of duplicates)

- Tipmail improved with Xmodem support

-several commands modifying interface flags have different syntax
(eg ax25 digipeat [<iface>] [on|off] )

-'repeat' command added

-new buck book drivers for int'l calls

-mailbox acces can be configured for bbs-only, sysop-only etc.
 per interface...

-no limit of 10 on convers-call/mailbox connections anymore

Lots and lots more; PLEASE read the README.NOW CAREFULLY !!!
There are quite a few things that have dramatically changed, and
need modifying of the autoexec.nos file !!!

Code is on wg7j.ece.orst.edu in /public/108,
and tomcat.gsfc.nasa.gov in /public/tcp/nos/wg7j/108

Ucsd.edu doesn't have write permissions anymore in incoming, so
it is not there :-(

Have fun,

Johan, wg7j

------------------------------

Date: Mon, 22 Feb 93 22:51:36 CST
From: [e-mail] (Dan Keizer)
Subject: jnos108 repeat query
To: [e-mail]

Just got 108 loaded down, tried out the pre-compiled version from johan, just
noticed that there appears to be some junk at the end of the line for
the repeat command .. ie:   repeat 1000 s
shows this.  Haven't had time to look into it, but thought i'd at least
let it be known.
Dan.
------------------------------------------------------------------------
Dan Keizer, VE4DRK      [e-mail] [44.135.124.25]
[e-mail]       VE4DRK@VE4KV (AX.25) Winnipeg, Manitoba Canada

------------------------------

Date: Mon, 22 Feb 93 22:56:20 -0800
From: [e-mail] (Chuck Bland)
Subject: ka9q0105 and ftpusers
To: [e-mail]

What, folks, am I doin' wrong...........

As promised, it appears ka9q0104 is trying to rewrite my ftpusers file
after hashing it. The problem is that it leaves me with a 0 length file
and no error messages anywhere explaining why.

I've strolled through the sources, but I'm not getting any better info on
why is isn't happy. Any clues, folks ?

I presume this must be some type of local problem ,since I haven't seen
any gripes here. Your help is appreciated.

Chucky
[e-mail]

------------------------------

Date: 22 Feb 1993 16:46:02 GMT
From: [e-mail] (Brian Kantor)
Subject: looooooooooooooooooooooooooooooooooooong messages
To: [e-mail]

In article <[e-mail]> [e-mail] (Jerzy Tarasiuk) writes:
>when you really need to send something long, *PLEASE* pkzip and
>uuencode it. And put some text info what it is. Your msg exceeded
>100kB and some mailers may have a little trouble handling it.
>Pkzip+uuencode would produce file 2 times shorter (50kB only)!
>73's, JT

Better yet, don't mail it to the group at all.  This is supposed to be a
DISCUSSION list, not a software distribution channel.  Use FTP.  Or mail
it only on request.

Am I going to have to install a 500-lines-max filter on this list also?

Jeez, people, use your alleged brains.
 - Brian

------------------------------

Date: Mon, 22 Feb 93 09:35:17 PST
From: [e-mail] (Jack Brindle)
Subject: looooooooooooooooooooooooooooooooooooong messages
To: [e-mail], [e-mail]

>when you really need to send something long, *PLEASE* pkzip and
>uuencode it. And put some text info what it is. Your msg exceeded
>100kB and some mailers may have a little trouble handling it.
>Pkzip+uuencode would produce file 2 times shorter (50kB only)!

Isn't it amazing that the simplest things can cause controversy...
I fully agree with the request to compress things that are so long.
What I disagree with is the method. It appears that the most universal
compression system is unix compress. This utility has been implemented
across almost all systems. Unfortunately PKZip has not. So, please,
if the file you wish to send is real long, use compress first...
Jack Brindle
------------------------------------------------------------------------------
ham radio: wa4fib                             internet: [e-mail]

------------------------------

Date: Mon, 22 Feb 93 22:50:44 GMT
From: [e-mail]
Subject: looooooooooooooooooooooooooooooooooooong messages
To: Jerzy Tarasiuk <[e-mail]>, [e-mail],

Jerzy Tarasiuk <[e-mail]> wrote:
>
>
> when you really need to send something long, *PLEASE* pkzip and
> uuencode it. And put some text info what it is. Your msg exceeded
> 100kB and some mailers may have a little trouble handling it.
> Pkzip+uuencode would produce file 2 times shorter (50kB only)!
> 73's, JT
>

Can I suggest an even better idea. Some of us are connected by dial-up links
and even 50K of msg costs! Please could you put it somewhere it can be ftp'd
and put a pointer here.

73. John

--
Office: [e-mail]
Home: [e-mail] || [e-mail] || G4REV @ GB7FLG

------------------------------

Date: Mon, 22 Feb 93 17:03:03 PST
From: "Jerzy Tarasiuk" <[e-mail]>
Subject: my BM mod
To: [e-mail]

Hello, all BM users

A feature of BM I (and one of my friends) don't like is it allows
to specify as recipient bare address only, not something like:
[e-mail] (Jerzy Tarasiuk)
I made a mod allowing it for bm332b, it is on zfja-gate file
mailer/bm-send.zip (contains only bm.h and send.c). Allows the
specified form on 's' command argument, and /alias file can have
lines like: jt [e-mail] (Jerzy Tarasiuk)
Specifying name on command line overrides name from alias file.

Few questions: 1. line 64 in original send.c was:
  if (tp->host != NULLCHAR || *tp->host != '\0') {
I suppose should be && instead ||, I changed it in my version;
2. when alias and name are specified on command line and alias
specifies more than one address, the name from command line
is put after every address, should it be or put after last only?
3. when OUTGOING mail is put in log, its beginning line is:

------------------------------

Date: Mon, 22 Feb 1993 13:12:49 +0000 (GMT)
From: [e-mail] (Mark Willis)
Subject: New ax25?
To: [e-mail]

>Lyndon Nerenberg <[e-mail]> writes;
>
>> Well, the callsign doesn't belong in every packet, either - it's extra
>
>So how else are you going to generate a unique and reproduceable address
>for that layer?

A while back AEA released a version of firmware for the PK-88 with a feature
called 'PK-Lite' which did some form of header compression. From what I
understand callsigns aren't sent in every packet, or maybe they are compressed?
Anyway, couldn't we do something like this?


>Digressing a fair bit, Phil mentions he would like to see some sort of
>"LAN" routing scheme setup below IP to give IP the fully connected network
>it wants.
>
>Instead of trying to patch IP we give it the sort of connectivity it
>assumes is present and design a protocol specifically to handle the
>problems a Radio network (such as we have) presents.

Well, I'm not familiar with that sort of protocol, but it sounds difficult.
Don't you eventually get into a position where you are sending huge routing
info packets every 30s/30m/whatever?  Must buy some 64k modems...

The other problem is that such a network might only be capable of routing
IP. Now I like that, but there's lots of other people round here who don't use
IP and don't see any need to. Do we build a network that excludes these people?

Whats actually *wrong* with protocols like RSPF ? I know it has problems in
multiport-one-ip-address situations, but what is it like in practice in big
amateur ip networks? I only ask because there are so few people running IP here
in GI that I can't evaluate these things.

>+--------------
>| IP
>+--------------
>| "LAN" connectivity protocol
>+--------------
>| Link protocol
>+--------------
>
>It would present to IP a model of the network pretty much as if was a
>*very* slow ethernet.
>
>It would need to support the following;
>
>Broadcasts,
>Multicasts,
>Point to point unreliable, unconnected delivery.
>
>Full and half duplex links,
>One way and multiple paths,

p-p unreliable unconnected over a smart network is probably the most useful.
Support for full & half duplex should be mandatory.

>Carl.
>vk1kcm.

-mark
--
Mark Willis                   Internet:  [e-mail]
ICS Computing Group Ltd.      UUCP:      ...uknet!icsbelf!markw
Northern Ireland              Packet:    GI0PEZ@GB7TED.#63.GBR.EU
Belfast                       AmprNet:   [e-mail] [44.131.15.3]

------------------------------

Date: Mon, 22 Feb 1993 09:55:01 -0600
From: [e-mail] (Milton Miller)
Subject: New ax25?
To: [e-mail]

In message <[e-mail]>, Lyndon Nerenberg <[e-mail]> writes:
> > So how else are you going to generate a unique and reproduceable address
> > for that layer?  Using the callsign of the station with some other
> > identifying information makes it reasonably easy to keep the identification
> > unique.
>
> Well, the address only has to be unique within the subset of stations
> that can hear each other. I would use a 16 bit station address. When
> a station comes on the air it picks a random value and broadcasts it
> out the appropriate port. If the address is already in use the existing
> address holder sends out a "sorry, try another one" reply, and the
> process repeats until a unique address is found. (Now where have I
> seen *that* before :-)
>
> --lyndon
>

Which very quickly breaks because X can hear Y but not vice versa, or,
even more common, Z can hear X and Y, but they can't hear each other :)
(Or X is temporally mute and/or deaf because of operator error and never
really sends the "Is this address in use?")

milton


PS: Regarding the message delays, I went 3 days last week without
getting a single message.  I have also seen 3 messages from Phil Karn
duped (don't know if they were just duped to me or not, not worth going
back through the headers yet).  This address was added about a year
ago, to give some an idea where it is in the list.

------------------------------

Date: Mon, 22 Feb 1993 10:36:38 -0500
From: [e-mail] (C. Harald Koch)
Subject: New ax25?
To: [e-mail] (Chris Cox W0/G4JEC)

> That, however, then requires that you know our ip address prior to
> setting a link address.  rarp/bootp would not work then.  I doubt it's
> used very much over radio, however, it would be useful.

Well, in order to talk to you using IP, I have to know your IP address :-)
But I see your point.

> Is there any great reason why your callsign should not make up part of
> the link address, or at least use it as seed for an address?  It is useful
> in that it is unique.

As a seed for an address, I suppose it's OK. The problem is that call-signs
are variable length objects, which are difficult to handle. The current
scheme of reserving six characters is flawed, because there are callsigns
longer than six characters out there (witness special event stations).

Having said all that, I don't have a better solution to offer. :-)

--
Main's Law: For every       | C. Harald Koch  Alias Research, Inc. Toronto, ON
action, there is an equal   | [e-mail]                (work-related mail)
and opposite goverment      | [e-mail]     (permanent address)
program.                    | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)

------------------------------

Date: Mon, 22 Feb 1993 11:03:44 -0800
From: Lyndon Nerenberg <[e-mail]>
Subject: New ax25?
To: [e-mail], [e-mail], [e-mail],



------------------------------

Date: Mon, 22 Feb 93 00:58:39 -0800
From: [e-mail] (Phil Karn)
Subject: New ax25?
To: [e-mail], [e-mail], [e-mail]

> I strongly disagree. Putting both callsigns into each frame was one
> thing (and probably the only thing) AX.25 did right.

Can you elaborate? I don't understand the big win.

> If you really want to reduce overhead in a packet system, the secret
> lies in educating the *upper layer* protocols to generate fewer and
> larger packets whenever possible. I can think of all sorts of
> examples: the Nagle algorithm in TCP (widely implemented) and Linemode
> Telnet (unfortunately not yet very widely implemented) are two that

But why stop at the upper layers? The picture I have is of people
running emacs over the radio. (Sick, or what? :-)  At that point linemode
telnet doesn't help. It is the nature of the application to generate
little tiny one or two character data packets that need to get to their
destination fast. Why should I delay transmission of a single character
packet by a factor of eight (assuming 32 bit address fields) just so I
can include some verbose addressing information that I don't necessarily
need to operate over the link? (Yes, the above numbers are a bit flawed -
I'm not taking header sync bits into account. If I do the X8 decrease
is reduced somewhat.)

If you *insist* in putting a callsign into the header, provide an
option field for it. Don't use it for addressing.

--lyndon

------------------------------

Date: Tue, 23 Feb 1993 11:46:15 +1000
From: [e-mail]
Subject: New ax25?
To: [e-mail]

Mark Writes;

> A while back AEA released a version of firmware for the PK-88 with a feature
> called 'PK-Lite' which did some form of header compression. From what I
>  understand callsigns aren't sent in every packet, or maybe they are compressed?
> Anyway, couldn't we do something like this?

Sure, we could design something that used callsigns at link establishment
and then used a negotiated token from then on, but the question is really
why?  Is it worth the hassle writing this to save up to 32 bytes?
Especially as higher speed networks are becoming more common.  I personally
don't think so however I can see this becoming a religious war. :-(

>> Digressing a fair bit, Phil mentions he would like to see some sort of
>> "LAN" routing scheme setup below IP to give IP the fully connected network
>> it wants.

>> Instead of trying to patch IP we give it the sort of connectivity it
>> assumes is present and design a protocol specifically to handle the
>> problems a Radio network (such as we have) presents.

> Well, I'm not familiar with that sort of protocol, but it sounds difficult.
> Don't you eventually get into a position where you are sending huge routing
> info packets every 30s/30m/whatever?  Must buy some 64k modems...

You wouldn't have all of California (for example) known at this
"sub-network" layer.  Just the "subnet" for the area you are in and the
gateway out.  Routing information could be sent "on demand" and
periodically as well (just like RIP or NETROM) and needn't be huge.

Actually, before we look at routing information we'd better look at how
this "sub-network" layer could work.

The way I see it we can go either of two ways.

1) Every station is a full routing member of the "sub-network" or

2) We use a HUB/CLIENT configuration where we have designated HUBS which
are known throughout the area and CLIENTS which are known to nobody but
themselves.

Each has their advantages and disatvantages although I personally favour
option 2.  Of course we can mix them to a large extent. :-)

> The other problem is that such a network might only be capable of routing
> IP. Now I like that, but there's lots of other people round here who don't use
> IP and don't see any need to. Do we build a network that excludes these people?

Why are they excluded?  We have AXIP, we can pass AX25 over IP as a worse
case, or we can provide gateways (such as Nos does now) into an IP network.


> Whats actually *wrong* with protocols like RSPF ? I know it has problems in

Well, from my understanding the biggest problem is that it is trying to
deal with a situation with which IP wasn't designed to handle.

> p-p unreliable unconnected over a smart network is probably the most useful.
> Support for full & half duplex should be mandatory.

Broadcasts are also mandatory and if we are building a new protocol we
might as well include things like multicasts in NOW!

Carl,
vk1kcm.
--
Carl Makin   (VK1KCM)  Systems Programmer
Internet:    [e-mail]
Amprnet:     [e-mail]
Work Phone:  [phone]

------------------------------

Date: Mon, 22 Feb 1993 08:55:30 -0600 (CST)
From: Steve Sampson <[e-mail]>
Subject: On dealing with radar
To: [e-mail]

Phil Karn <[e-mail]> writes ..
> Consider a typical military radar with a 400 Hz rep rate, a 8 Mhz bandwidth,
> a 10 second antenna sweep rate, and a 20 microsecond pulse width (this
> latter figure is the most uncertain, I estimated it with an HP spectrum
> analyzer set in "zero span" mode with the fastest possible sweep, 50 us/div).

Adrian Godwin <[e-mail]> writes..
> Is there just one radar transmitter, or several unsynchronised transmitters?

My first thought was E-2 radar (Navy) but I think they operate up a little
higher in frequency, so I wonder if it's not an old DEW line radar that I used
to work on in the 70's, because the range is too short (200 nm) for airborne
use.  They should have replaced that pig with a microwave 3D radar by now!  By
the time you get the FEC all worked out they'll probably then decide to upgrade
- hee.  The object, was that you needed a big Soviet ship or cargo plane to
carry anything big enough to jam it, but with the majority of air defence
radars being microwave now, you'd bypass those beasts anyway...

But generally you don't have many radars in close proximity, so I don't
suspect you'll run into the problem of multiple radar interference even at
microwave packet, which is where high speed packet belongs.  Since 2m packet
is such a wasteland, any new protocol for user access should just push those
old TNC's into the ocean.  That'll solve your 440 problem, use it for voice.
---
Steve, N5OWK

------------------------------

Date: Mon, 22 Feb 93 9:11:53 PST
From: Glenn Elmore <[e-mail]>
Subject: physical layer and FEC engineering
To: [e-mail]

Phil writes:

> Glenn, I used to think as you did about FEC -- that it was something you did
> as a last resort to patch up a bad radio channel, when you couldn't fix the
> actual problem (e.g., by running more power.) But if I've learned anything
> from the CDMA cellular project here at Qualcomm, it's that FEC is essential
> in wringing maximum performance out of a radio system, even when you have
> the option of increasing transmitter power or using a better antenna.

  First, thanks for your thoughts.  I appreciate the feedback a lot as
at times I feel like I'm out here in left field winging it on my own.

  I may not have clearly stated my belief (or else you changed my mind
more than I noticed (:> ) WRT the place and value of FEC, power control
etc.  The next version of hardware has room for both even though I'm not
yet sure about the form of FEC in it.

  I don't view FEC as a last resort.  I see it as a necessary but
insufficient condition of effective radio link operation.  Also, I
definitely don't see running excess power as the solution.  I think
that simply shifts the problem without improving the fundamental
utilization of the resource.

  Also, I think that the environment in which we are trying to optimize,
amateur radio, is considerably different from what Qualcomm is doing.
Not that radio propagates differently for that project, but that the
constraints and goals are a lot different.  One of the differences is
user density.  Another difference is mean path length.  Another
difference is funding and support.  I believe that the
user$'s/mean_path_length^^2 (or some such metric) is extremely
different.  Also Qualcomm may be able to afford a high degree of
integration and be able to cough up enough money to provide the catalyst
necessary to demonstrate a very different kind of network from that
which AR is capable.  I think there are going to be some substantial
differences in implementation because of these differences in climate.

> One good reason is spectral efficiency. Efficient spectrum use means a high
> degree of geographic channel reuse (i.e., a cellular scheme), which implies
> that the system is ultimately interference (not noise) limited. To pack

  I think this may be almost a non-issue for AR.  Being interference
limited at the kinds of user densities and with the spectrum AR has is
probably unneccessary, and for many hams it is impossible.  As I pointed
out in my physical layer CNC paper, the realities of terrestrial
propagation and a spherical earth effectively limit the sphere of
influence.  Many uhf-microwave weak signal types would love to have
another user withing range that could communicate and "interfere" with
them.
  This may *not* be the case for the users Qualcomm is seeking to serve
in a metropolitan area with a link from every other car and one in every
home.  Still I expect that if such a network is ever going to be truly
wide area that there will be a great many situations where interference
from other users is not a problem and the physical hardware may be noise
limited.  How many competing users are there likely to be out in the
middle of a corn field in Iowa or at the bottom of the Grand Canyon?
Probably less than a hundred.

> co-channel users as closely as possible, you want a modulation method with
> the greatest possible resistance to interference. Even if this makes the
> signal much wider, you're still better off in the end.

Agreed.  Probably especially *if* it makes the signal wider (reference
Shannon).  Whether the degrading influence is multipath, QRM or QRN we
have to minimize it's impact.

> Spread spectrum is of course the way to do this, but FEC also plays
> an important part. By reducing the average required transmitter power 5 dB

SS is part of the solution.  Again, necessary at times but not
sufficient.


> Consider a typical military radar with a 400 Hz rep rate, a 8 Mhz bandwidth,
>
> If the pulses were really short, i.e., on the order of 1/bandwidth, then
> even at 56kb/s a simple pulse blanker would be very effective at dealing
> with it. Unfortunately the radar pulses are much longer than they have to be
>for the bandwidth they use, probably because of either pulse compression and/or
> simple pulse broadening to increase target sensitivity. Because the pulse
> durations are comparable to an entire bit time at 56 kilobits, a pulse blanker
> would remove entire data bits along with the radar pulses.
>
> Let's say that your link is otherwise reasonably well engineered, so most
> of your channel bit errors are due to radar pulse hits. Let's also assume
> that the radar pulses, when they occur, are much stronger than the data
> bits themselves -- say by 40 dB or so. To overcome the radar QRM by brute
> force, you'd have to make up that 40 dB by either turning up the wick by
> that amount (probably not practical, as well as not legal, especially in
> one of the 50W limit zones), or by using antennas with that much additional
> gain and/or sidelobe suppression (difficult if not impossible when you
> consider scattering.


This is the crux of the physical layer problem I was addressing.  While
it shows off the value of FEC it also points to the fundamental problem
that FEC is "curing".

  From the hardcore physical layer view of things, the presence of such
a radar is pretty insignificant.  The reduction in capacity from 400,
100 nanosecond long "outages" every second is only .004%, your crystal
controlled data clock could drift that far and have the same impact on
utilizing the available channel capacity as predicted by Shannon.  Even
if the pulses are stretched due to system nonlinearites or whatever and
take a hit for an entire bit time at 56 kbps you're only losing 400/56K
and you're still not even up to 1% degradation yet.

> Or you can use FEC. If the pulse rep rate is 400 Hz and your data rate is
> 56kb/s, then the radar will hit, at most, one or two data bits out of every
> 56000/400 = 140. That's a channel bit error rate of 1%, in round numbers,
> which is much too high for good performance without FEC.  And cranking up
> the wick won't do anything to lower this error rate until you swamp the
> radar's power, which we already know is impractical.

   This problem really isn't a physical layer one (well I'm not sure
where FEC sits, sort of perched on the fence between L1 and L2 depending
on the implementation isn't it?)  it's that " you're letting a few
errors spoil your whole day".  The actual channel capacity really hasn't
degraded (been shared) much.  FEC offers a graceful way for performance
to degrade along with it.  Instead of wiping out kilobits of data
because a few were wrong, it lets things continue with just a little
overhead and slowdown.  This is definitely good stuff.  But, it doesn't
solve the physical layer problem I was referring to in my original
posting.

>But it's *easy* to build FEC systems that handle channel bit error rates of 1%.

> at relatively low error rates like 1% it has no problem keeping up with a
> 56kb/s modem with time to spare on a 33 Mhz 486. The chances of an
> uncorrected error at this rate
> are nil for all practical purposes, so the effective coding gain in this case
> is equal to the amount of power you'd have to run to get the same effect by
> simply cranking up the wick -- 40 dB in this example. That's a pretty
> impressive figure!

  I disagree.  From a channel capacity view that's not a fair
comparison.  Turning up the power or other hardware budget variable by
40 dB is *not* how to solve a .7% degradation in channel capacity which
caused *all* data to be lost and "threw away" all the remaining channel
capacity.  The precise cure depends on the cause of degradation.  SS to
combat multipath, directional antennas/higher frequencies to allow
better reuse and lower interference all of which are likely to cause
massive or total errors, FEC to handle bit errors when they start to
climb out of the very-small range, or other means may be indicated.
Dynanmic capacity adaptation is necessary to the degree that paths/links
aren't stable.  This instability and variability can be huge if we
aren't careful.  To that degree, all of these "fixes" are bandaids
covering a more serious problem.

  I think we are pretty much in agreement but this demonstrates the
differences of the areas we are discussing.  I agree that FEC and
spreading are vital to keep imperfections in the system from causing
immediate and total collapse.  My original comment was that we have to
engineer the underlying layer, paths, antennas etc so that we *have* a
channel working near optimum capacity to begin with.  AR can't afford
the overhead (like 40 dB excess power capability) to make up for a link
that was poorly designed to begin with.  At least not if we want a wide
area network which can has a significant information content.

  Both link engineering and graceful adaptation to capacity changes,
whether induced by multipath, QRN or QRM, are necessary.  Both
engineered paths and FEC/power control are necessary but neither is
sufficient in itself.

> You choose a "systematic" convolutional code where the original data appears

> What's really neat about this is that both frames (the original one plus
> the encoded one) can be riddled with errors, but as long as the rate isn't
> higher than about 6 or 7%, the decoder will quickly recover good data from the
> combination. This makes it *much* more efficient than simply resending the
> unencoded frame over and over in the hope that it will get through without
> any errors -- which is pretty unlikely if the average error rate is that high.

  This sounds like good territory but we have to remember to keep this
in context of a lower layer which can easily degrade by 10,000% if we
don't properly implement it.
  Given the AR environment, which probably won't be able to afford 486+
capacity to perform the FEC you suggest inside an
xyl-approved-price-range digital/radio/antenna interface to a wide area
amateur network, what sorts of FEC implementations might make sense?
Specifically, what kind of hardware might I consider including in the
next radios I'm working on?

> These little 2-3 dB factors really start adding up. If you go from a
> non-coded noncoherent demodulator to a coherent demodulator with a
> well designed soft decision rate 1/2 FEC, you can easily save as much
> as 8dB on transmitter power. This should be very attractive in some
> places (like satellites). And as I said yesterday, the effective
> coding gains against non-thermal noise such as radar pulses can be
> far higher, even with relatively simple FEC.

  I am running fully coherent and in addition to normal data slicer, I'm
leaving access to and from the direct I&Q modulators so that analog,
digital or DSP techniques can be applied when/where they work and are
indicated.  With approriate DSP, these radios should be able to
modulate/demodulate SSB as well as the digital modulation mode/speed of
your choice.

  Pointers to simple FEC implementations which could offer considerable
return for low end investment and which might also work in concert with
higher capability hosts (486's working on 256kbps bit streams?)  will be
appreciated.  Is anyone on this list actively working on hardware, or
largely hardware, FEC implementations?  My hands are more than full with
just the "baseband delivery" side of things.


73
Glenn n6gn

------------------------------

Date: Tue, 23 Feb 93 10:53:06 +1100
From: [e-mail] (Warren Toomey)
Subject: redoing amateur packet
To: Glenn Elmore <[e-mail]>, [e-mail]

In atricle by Glenn Elmore:
>
> Phil wrote:
>
> > At 10:37 2/9/93 -0800, Jeffrey D. Angus wrote:
> >
> > >KISS Mode? The only things that would have to stay constant while re-using
> > >existing TNCs are the BELL-202 modem and the 8530 HDLC.
> >
> > Actually, if you really want to redo amateur packet radio right from
> > the ground up, even these have to go. I'm becoming convinced that some
> > form of forward error correction (FEC) is essential, at least as an
> > option when links get bad, and this pretty much precludes HDLC framing.
>
>   I see your SCC, TNC, FEC and I raise you an engineered physical layer.
> (:>)
>
>   I agree that existing hardware doesn't cut it and that FEC and power
> control are useful.  However, these seem to me to be bandaids on a bad
> situation or, at best, a form of adaptation necessary because the lower
> layer hasn't been more effectively utilized.
>

[ Much more deleted ] { Also back from hols & reading the backlog }

I agree that FEC isn't needed in some situations. Perhaps we need something
like the IEEE 802 set of standards, for amateur radio, viz:

 + One standard Logical Link Control layer that higher layers
   (either built into TNCs or NOS) use to get/receive packets.
   Packets have a standard format at this layer.

 + One or more Medium Access Control layers so that we can tailor
   them to particular situations, e.g FEC where bit error rates
   are high. If you're worried about hiving too many MACs running
   around, let's start with one, and design others as the need
   arises.

 + Several Physical layers. I guess these already exist as de-facto
   standards.

To sum up, a set of standards to choose from, but with a single access
point and format to allow higher software to be easily written.

 Warren vk1xwt

------------------------------

Date: Mon, 22 Feb 1993 12:43:46 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: Riff-raff and the internet?
To: John Paul Morrison <[e-mail]>

> the authentication is important if an internet 'wormhole' is established.
> (since Internet won't like having riff-raff invading the networks)

Well, there's no central management of the internet to object to us
"riff-raff". I'm working on an "open" gateway that would allow locals
unimpeded access to the internet after a simple telephone verification.
I can't put this on Pixar's internet connection because our access provider
restricts us from gatewaying our connection to other sites. Once, however,
you get by the local access provider, the internet is a free-for-all (too
much so, in opinion). Since AMPRnet stations are official parts of the
internet, what's the problem?
     Bruce Perens

------------------------------

Date: Tue, 23 Feb 93 08:18:15 +1100
From: [e-mail] (Mike Walker)
Subject: Slow Mail
To: [e-mail]

36 to 48 hours seems to be the norm for any tcp-group messages
down here.

Mike

------------------------------

Date: Mon, 22 Feb 93 08:49:21 -0800
From: brian (Brian Kantor)
Subject: Slow mail?
To: tcp-group

>For the last week or so the mail from the tcp-group mailing list has been
>taking several days (often a week) to reach my site.  The headers show that
>the articles reach ucsd.edu in a timely manner, but then take days for the
>single hop from ucsd to me.

UCSD has had some troubles lately, but I think you'll find mail is
moving faster once again.
 - Brian

------------------------------

Date: Mon, 22 Feb 93 08:50:47 -0800
From: brian (Brian Kantor)
Subject: Slow mail?
To: tcp-group

>I've had a three-or-four day lag that usually catches up at weekends - but this
>is the digest, on 'Bulk' precedence, so that seems reasonable if ucsd is
>handling a lot of mailing traffic.

I dunno if it's a lot; on an average day, we deliver between 30 and 35 thousand
pieces of mail.
 - Brian

------------------------------

Date: Mon, 22 Feb 1993 13:50:46 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: stat() in Borland C++
To: [e-mail]

On Sat, 20 Feb 1993 [e-mail] wrote:

> The stat() function in Borland C++ uses the realloc() function, although
> I have no idea for what. I don't know for certain
> certain what the effects of running Borland's realloc() against a block
> allocated by NOS's malloc() would be, but I suspect it wouldn't be pretty.

[OK, keep talking about stat(). See what an awful thought cop I am :-) ]

If you are supplying your own malloc() and free() (or KA9Q is), you can
avoid conflict with realloc() by supplying your own realloc():

void *
realloc(void * original_buffer, size_t size)
{
 void * new_buffer = malloc(size);
 size_t old_size = ...
 /*
  * old_size is the size of original_buffer.
  * Fill that in here. I don't have the
  * KA9Q source in front of me, so you'll have to figure that
  * out from your source for malloc() and free().
   */
 if ( new_buffer ) {
  memcpy(new_buffer, original_buffer, old_size);
  free(original_buffer);
 }
 return new_buffer;
}

This may even be what the Borland code does, but we can't trust it.
Realloc has the option to work in-place (return the same address as
old_buffer, with a bigger buffer), but it is not necessary to emulate
that behavior.

If we're going to replace the allocator, we should replace _all_ of its
entry points, otherwise some library code that calls one of them may
clobber us. My ANSI C reference says those are calloc(), free(),
malloc(), realloc(), and there may be others on your platform.

I kind of think ANSI should have left realloc() and calloc() out of the
standard, but now we are stuck with providing them.

     Bruce Perens

------------------------------

Date: Mon, 22 Feb 1993 12:32:05 -0800 (PST)
From: Bruce Perens <[e-mail]>
Subject: Stat - Hello wake up !
To: [e-mail]

If you feel this way, you should really unsubscribe from the list.

     Bruce


On Fri, 19 Feb 1993 [e-mail] wrote:

> There are times people really annoy me too Alan, and this is one of those
> times. I too am getting really tired of this conversation and your ignorant
> remarks, not only on stat() but OS's as well. As far as the stat issue goes,
> I've been conspicuously silent of late on the subject. So, Alan, WAKE UP. Dont
> beat a dead horse. Frankly I really dont care what you think abt language
> facilities, since you obviously dont have a good grasp on the subject. My
> suggestion to Doug was sent thru the group because of routing requirements thru
> milnet, it was not intended to be a general discussion. The most pervasive
> reason to not use stat is it doesnt work, atleast for Doug.  So, in closing, I
> would suggest that you and Bruce (and anyone else wanting to enter the fray)
> decide amongst yourselves who is to be the self appointed thought police and
> label your msgs as such. That way the rest of us will have a better idea of
> what to ignore. Have a nice day. Walt
>

------------------------------

Date: (null)
From: (null)
Take it and enjoy. Thanks in advance for any report on
new bugs (not present in bm332b = caused by my modification).
73's, JT

------------------------------

End of TCP-Group Digest V93 #51
******************************
******************************